ZAP Scanning Report

Une injection SQL peut être possible.

Ne faites pas confiance aux entrées du côté client, même si des mécanismes de validation sont en place côté client.

En général, contrôlez du côté serveur le type de chaque donnée.

Si l'application utilise JDBC, utilisez les PreparedStatement ou CallableStatement, avec les paramètres passés par '?'

Si l'application utilise ASP, utilisez les Objects de Commande ADO avec un typage fort et des requêtes paramétrées.

Si l'utilisation de Procédure Stockées est possible, utilisez-les.

Ne concaténez *pas* les chaînes de caractères dans les requêtes des procédures stockées, ou utilisez les fonctions 'exec', 'exec immediate' ou d'autre fonctions équivalentes!

Ne créez pas des requêtes SQL dynamiques par simples concaténation de chaînes de caractères.

Échappez toutes les données reçues du client.

Appliquez une 'liste blanche' des caractères autorisés, ou une 'liste noir' des caractères interdits dans les entrées de l'utilisateur.

Appliquez le principe de moindre privilège en utilisant les privilèges utilisateur minimaux sur la base de donnée.

En particulier, évitez l'utilisation des utilisateurs 'sa' ou 'db-owner'. Ceci n'évite pas les injections SQL, mais minimise leur impact.

Accordez les plus faibles droits d'accès aux bases de données nécessaires à l'application.

SGBDR [MySQL] probable, compte tenu du message d'erreur spécifique à l'UNION, trouvé par l'expression régulière [\QThe used SELECT statements have a different number of columns\E] dans les résultats HTML.

La vulnérabilité a été détectée dans le message d'erreur provoqué par la manipulation du paramètre d'une clause SQL 'UNION'.

https://www.owasp.org/index.php/Top_10_2010-A1

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Le cross-site Scripting (XSS) est une technique d'attaque consistant à retourner du code fourni par l'attaquant à une instance de navigateur d'un utilisateur. Une instance de navigateur peut être un navigateur standard, un objet navigateur incorporé dans un produit logiciel (p.ex. le navigateur dans WinAmp), un lecteur RSS ou un client de messagerie. Le code lui-même est généralement écrit en HTML/JavaScript, mais peut être aussi en VBScript, ActiveX, Java, Flash ou toute autre technologie supportée par les navigateurs.

Lorsqu'un pirate parvient à faire exécuter son code par le navigateur d'un utilisateur, le code s'exécute dans le contexte de sécurité (ou zone) du site web hébergeur. Avec ce niveau de privilège, le code a la capacité de lire, modifier et transmettre toutes les données sensibles accessibles par le navigateur. Un utilisateur sujet au Cross-site Scripting pourrait voir son compte piraté (vol de cookie), son navigateur redirigé vers un autre site, ou éventuellement voir apparaître du contenu frauduleux envoyé par le site internet qu'ils visitent. Les attaques par Cross-site Scripting compromettent fondamentalement la relation de confiance entre un utilisateur et le site web. Les applications utilisant des instances d'objet de navigateur, et qui chargent du contenu depuis le système de fichiers, peuvent exécuter du code dans le périmètre de confiance de l'ordinateur, mettant ainsi en danger le système.

Il existe trois types d'attaques par Cross-site Scripting : non persistant, persistant et basé sur les DOM.

Les attaques non persistantes et celles basées sur les DOM nécessitent qu'un utilisateur visite un lien incorporant un code malveillant, ou visite une page web malveillante contenant un formulaire internet, qui, une fois publié sur le site vulnérable, permettra l'attaque proprement dite. Un formulaire malveillant sera souvent utilisé lorsque la ressource vulnérable n'accepte que les requêtes HTTP POST. Dans un tel cas, le formulaire peut être envoyé automatiquement, sans que la victime n'en ait conscience (p. ex. à l'aide de JavaScript). En cliquant sur le lien malveillant ou en soumettant le formulaire malveillant, le code XSS s'affichera en retour et sera interprété et exécuté par le navigateur de l'utilisateur. Une autre technique pour envoyer des requêtes presque arbitraires (GET et POST) consiste à utiliser un client intégré, tel que Adobe Flash.

Les attaques persistantes se produisent lorsque le code malveillant est envoyé à un site internet où il est stocké pendant un certain temps. Des exemples de cibles favorites des pirates sont les publications sur les tableaux de messages, les messages de courrier électronique et les logiciels de tchat internet. Aucune interaction avec un quelconque site/lien supplémentaire (par exemple, un site de pirate ou un lien malveillant envoyé par e-mail) n'est requis de la part de l'utilisateur sans méfiance, il suffit de visualiser la page internet contenant le code.

Phase: Architecture et Design

Utilisez une librairie ou un framework approuvé qui ne permet pas cette vulnérabilité, ou qui contient des fonctionnalités permettant d'éviter plus facilement cette vulnérabilité.

Quelques exemples de bibliothèques et de frameworks facilitant l'encodage approprié des pages internet sont: la bibliothèque Microsoft Anti-XSS, le module d'encodage OWASP ESAPI, et Apache Wicket.

Phases: Implémentation; Architecture et Design

Tenez compte du contexte dans lequel vos données seront utilisées et de l'encodage qui sera attendu. Ceci est particulièrement important lors de la transmission de données entre les différents composants, ou lors de la génération de sorties qui peuvent contenir plusieurs encodages en même temps, comme des pages internet ou des messages électroniques multi-parties. Étudiez tous les protocoles de communication et les représentations de données attendus pour déterminer les stratégies de codage requis.

Pour toutes les données qui seront affichées sur une autre page web, en particulier toutes les données qui ont été reçues de l'extérieur, utilisez l'encodage approprié pour tous les caractères non alphanumériques.

Consultez le XSS Prevention Cheat Sheet pour plus de détails sur les types d'encodage et d'échappement dont vous pouvez avoir besoin.

Phase : Architecture et Design

Pour tous les contrôles de sécurité effectués du côté client, veillez à ce que ces contrôles soient réitérés du côté serveur également, afin d'éviter la faille CWE-602. Les agresseurs peuvent contourner les contrôles côté client en modifiant les valeurs après que ces contrôles aient été effectués, ou en changeant le client afin d'en retirer complètement les contrôles. Ensuite, ces valeurs modifiées seraient soumises au serveur.

Le cas échéant, utilisez des mécanismes structurés appliquant automatiquement la séparation entre le code et les données. Ces mécanismes peuvent être en mesure de fournir automatiquement la présentation, le codage et la validation adéquat, au lieu de se fier au développeur pour réaliser ces fonctionnalités pour chaque champ de sortie généré.

Phase: Implémentation

Pour chaque page internet générée, utilisez et spécifiez un encodage de chaînes de caractères comme ISO-8859-1 ou UTF-8. Quand aucun codage n'est spécifié, le navigateur web tente de deviner quel encodage est effectivement utilisé dans la page web et peut choisir un codage erroné. Ceci peut pousser le navigateur internet à traiter spécialement certaines séquences, exposant ainsi le client à de subtiles attaques XSS. Voir CWE-116 pour des mesures de réduction de risque plus liées à l'encodage / l'échappement.

Pour aider à réduire les attaques XSS contre le cookie de session de l'utilisateur, fixez la valeur du cookie à HttpOnly. Dans les navigateurs prennant en charge la fonctionnalité HttpOnly (telles que les versions les plus récentes d'Internet Explorer et de Firefox), cet attribut peut éviter que le cookie de session de l'utilisateur soit accessible à des scripts malveillants utilisant document.cookie côté client. Ce n'est toutefois pas une solution complète, car HttpOnly n'est pas supporté par tous les navigateurs. Plus important encore, XMLHTTPRequest et d'autres puissantes technologies de navigateur fournissent un accès en lecture aux en-têtes HTTP, y compris à l'en-tête Set-Cookie, dans laquelle la balise HttpOnly est définie.

Supposez que toutes les entrées sont malveillantes. Utilisez une stratégie de validation des entrées basée sur le principe "n'accepter que le bon", c'est-à-dire utilisez une liste blanche des entrées acceptables se conformant strictement aux spécifications. Rejetez toute entrée ne se conformant pas strictement aux spécifications, ou transformez-la en une valeur qui soit conforme. Ne vous fiez pas exclusivement à la recherche d'entrées malveillantes ou incorrectes (par exemple, ne comptez pas sur une liste noire). Toutefois, les listes noires peuvent être utiles pour détecter les attaques potentielles ou pour déterminer quelles entrées sont si mal formées qu'elles devraient être rejetées purement et simplement.

Lorsque vous effectuez une validation d'entrée, considérez toutes les propriétés potentiellement pertinentes, comme la longueur, le type d'entrée, la gamme complète des valeurs acceptables, les entrées manquantes ou défectueuses, la syntaxe, la cohérence dans des domaines connexes et la conformité aux règles métier. Comme exemple de logique de règle métier, "bateau" peut être syntaxiquement valide car elle ne contient que des caractères alphanumériques, mais elle n'est pas valide si des couleurs sont attendues, telles que "rouge" ou "bleu".

Veillez à effectuer une validation d'entrée à des interfaces bien définies au sein de l'application. Ceci aidera à protéger l'application, même si un composant est réutilisé ou déplacé ailleurs.

http://projects.webappsec.org/Cross-Site-Scripting

http://cwe.mitre.org/data/definitions/79.html

La technique d'attaque par traversée de chemin d'accès (path traversal) permet à un pirate d'accéder aux fichiers, répertoires et commandes résidant potentiellement en dehors du répertoire racine des documents internet. Un agresseur peut manipuler une URL de telle sorte que le site internet exécutera ou révélera le contenu de fichiers arbitraires situés n'importe où sur le serveur internet. Tout dispositif qui expose une interface HTTP est potentiellement vulnérable à la traversée de chemin.

La plupart des sites internet restreignent l'accès de l'utilisateur à une partie spécifique du système de fichiers, généralement appelée la "racine des documents internet" ou le répertoire "Racine CGI". Ces répertoires contiennent les fichiers destinés à l'accès des utilisateurs et les exécutables nécessaires au fonctionnement des applications internet. Pour accéder aux fichiers ou exécuter des commandes situées n'importe où dans le système de fichiers, les attaques par traversée de chemin utiliseront les capacités de séquences de caractères spéciaux.

L'attaque par traversée de chemin la plus élémentaire utilise la séquence de caractères spéciaux "../ " pour modifier l'emplacement de la ressource demandée dans l'URL. Bien que la plupart des serveurs internet les plus populaires empêcheront de sortir de la racine des documents internet par cette technique, des encodages alternatifs de la séquence "../" peuvent aider à contourner les filtres de sécurité. Ces variations de la méthode incluent le codage Unicode valide et non valide ("..%u2216" ou "..%c0%af ») de la barre oblique, des barres obliques inverses ("..\") sur des serveurs Windows, des caractères en codage d'URL ("%2e%2e%2f"), et le double codage d'URL ("..%255c") de la barre oblique.

Et même si le serveur internet limite correctement les tentatives de traversée de chemin d'accès dans le chemin d'URL, une application internet peut encore être elle-même vulnérable en raison d'un mauvais traitement des entrées fournies par l'utilisateur. Il s'agit d'un problème commun des applications internet qui utilisent des mécanismes de modèle ou qui chargent du texte statique à partir de fichiers. Dans des variantes de cette attaque, la valeur du paramètre de l'URL originale est remplacée par le nom de fichier de l'un des scripts dynamiques de l'application internet. En conséquence, les résultats peuvent révéler le code source, parce que le fichier est interprété comme du texte plutôt que comme un script exécutable. Ces techniques utilisent souvent des caractères spéciaux supplémentaires, tels que le point ("."), pour révéler le listage du répertoire de travail courant, ou des caractères NULL "%00" afin de contourner des contrôles rudimentaires de l'extension des fichiers.

Supposez que toutes les entrées sont malveillantes. Utilisez une stratégie de validation des entrées basée sur le principe "n'accepter que le bon", c'est-à-dire utilisez une liste blanche des entrées acceptables se conformant strictement aux spécifications. Rejetez toute entrée ne se conformant pas strictement aux spécifications, ou transformez-la en une valeur qui soit conforme. Ne vous fiez pas exclusivement à la recherche d'entrées malveillantes ou incorrectes (par exemple, ne comptez pas sur une liste noire). Toutefois, les listes noires peuvent être utiles pour détecter les attaques potentielles ou pour déterminer quelles entrées sont si mal formées qu'elles devraient être rejetées purement et simplement.

Lorsque vous effectuez une validation d'entrée, considérez toutes les propriétés potentiellement pertinentes, comme la longueur, le type d'entrée, la gamme complète des valeurs acceptables, les entrées manquantes ou défectueuses, la syntaxe, la cohérence dans des domaines connexes et la conformité aux règles métier. Comme exemple de logique de règle métier, "bateau" peut être syntaxiquement valide car l'entrée ne contient que des caractères alphanumériques, mais elle n'est pas valide si vous attendez des couleurs telles que "rouge" ou "bleu".

Pour les noms de fichiers, utilisez des listes blanches rigoureuses qui limitent le jeu de caractères à utiliser. Si possible, ne permettez qu'un seul caractère "." dans le nom de fichier pour éviter les failles et excluez les séparateurs de répertoire comme "/". Utiliser une liste blanche des extensions de fichier autorisées.

Avertissement: si vous essayez de nettoyer vos données, faites-le alors de manière à ce que le résultat final ne soit pas sous une forme qui puisse être dangereuse. Un mécanisme d'assainissement peut supprimer des caractères tels que '.' et ';', qui peuvent être nécessaires pour certains exploits. Un agresseur peut essayer de tromper le mécanisme d'assainissement en transformant les données sous une forme dangereuse. Supposons que le pirate injecte un '.' à l'intérieur d'un nom de fichier (par exemple "sensi.tiveFile"), et le mécanisme d'assainissement supprimera le caractère, résultant en un nom de fichier valide, "sensitiveFile". Si les données d'entrée sont maintenant supposées sûres, alors le fichier peut être compromis.

Les entrées devraient être décodées et rendues canoniques selon la représentation interne actuelle de l'application avant d'en effectuer la validation. Assurez-vous que votre application ne décode pas la même entrée deux fois. De telles erreurs pourraient être utilisées pour contourner les contrôles par liste blanche en introduisant des entrées dangereuses après qu'elles aient été contrôlées.

Utilisez une fonction prédéfinie de canonisation du chemin (par exemple la fonction realpath() en C), qui produit la version canonique du nom de chemin, qui élimine efficacement les séquences ".." et les liens symboliques.

Exécutez votre code à l'aide des droits d'accès les plus réduits possible pour accomplir les tâches nécessaires. Si possible, créez des comptes isolés avec des privilèges limités, qui ne sont utilisés que pour une seule tâche. De cette façon, une attaque réussie ne donnera pas immédiatement accès au reste du logiciel ou de son environnement à l'agresseur. Par exemple, les applications de base de données ne nécessitent que rarement de fonctionner en tant qu'administrateur de base de données, en particulier dans les activités quotidiennes.

Lorsque l'ensemble des objets admissibles, tels que les noms de fichier ou les URLs, est limité ou connu, créez une correspondance à partir d'un ensemble de valeurs d'entrée fixe (tels que des ID numériques) sur les noms de fichiers réels ou sur les URLs, et rejetez toute autre entrée.

Exécutez votre code dans un "bac à sable" ou un environnement similaire, qui impose des limites strictes entre le processus et le système d'exploitation. Cela peut restreindre efficacement quels fichiers sont accessibles dans un répertoire particulier ou lesquels peuvent être exécutés par votre logiciel.

Au niveau du système d'exploitation, on peut citer les exemples pour Unix: chroot, AppArmor et SELinux. En général, le code géré (managed code) peut offrir une certaine protection. Par exemple, java.io.FilePermission dans le SecurityManager de Java permet de spécifier des restrictions sur les opérations de fichiers.

Ceci peut ne pas être une solution adéquate. Par ailleurs, elle limite l'impact au seul système d'exploitation; le reste de votre application peut encore faire l'objet de vulnérabilités.

http://projects.webappsec.org/Path-Traversal

http://cwe.mitre.org/data/definitions/22.html

Une injection SQL peut être possible.

Ne faites pas confiance aux entrées du côté client, même si des mécanismes de validation sont en place côté client.

En général, contrôlez du côté serveur le type de chaque donnée.

Si l'application utilise JDBC, utilisez les PreparedStatement ou CallableStatement, avec les paramètres passés par '?'

Si l'application utilise ASP, utilisez les Objects de Commande ADO avec un typage fort et des requêtes paramétrées.

Si l'utilisation de Procédure Stockées est possible, utilisez-les.

Ne concaténez *pas* les chaînes de caractères dans les requêtes des procédures stockées, ou utilisez les fonctions 'exec', 'exec immediate' ou d'autre fonctions équivalentes!

Ne créez pas des requêtes SQL dynamiques par simples concaténation de chaînes de caractères.

Échappez toutes les données reçues du client.

Appliquez une 'liste blanche' des caractères autorisés, ou une 'liste noir' des caractères interdits dans les entrées de l'utilisateur.

Appliquez le principe de moindre privilège en utilisant les privilèges utilisateur minimaux sur la base de donnée.

En particulier, évitez l'utilisation des utilisateurs 'sa' ou 'db-owner'. Ceci n'évite pas les injections SQL, mais minimise leur impact.

Accordez les plus faibles droits d'accès aux bases de données nécessaires à l'application.

Les résultats de la page ont été manipulés avec succès en utilisant les conditions booléennes [ZAP" AND "1"="1" -- ] et [ZAP" AND "1"="2" -- ]

La valeur du paramètre en cours de modification NOT est extraite de la sortie HTML à fin de comparaison

La donnée a été retournée pour le paramètre d'origine.

La vulnérabilité a été détectée en manipulant le paramètre, ce qui a restreint avec succès les données initialement retournées,

https://www.owasp.org/index.php/Top_10_2010-A1

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

La redirection d'URL représente une fonctionnalité communément employée par les sites internet pour transmettre une requête entrante vers une autre ressource. Cela peut être fait pour diverses raisons, et notamment souvent pour déplacer des ressources dans la structure de répertoire tout en évitant de casser la fonctionnalité pour les utilisateurs qui demandent la ressource à son emplacement précédent. La redirection d'URL peut également être utilisée pour distribuer la charge, tout en conservant les facilités des URLs abrégées ou de l'enregistrement des liens sortants. C'est cette dernière application qui est souvent utilisée dans les attaques de phishing comme décrit dans l'exemple ci-dessous. La redirection d'URL ne représente pas nécessairement une faille de sécurité directe, mais elle peut être utilisée par des agresseurs essayant de tromper des victimes en leur faisant croire par ingénierie sociale qu'ils accèdent à un site autre que la véritable destination.

Supposez que toutes les entrées sont malveillantes. Utilisez une stratégie de validation des entrées basée sur le principe "n'accepter que le bon", c'est-à-dire utilisez une liste blanche des entrées acceptables se conformant strictement aux spécifications. Rejetez toute entrée ne se conformant pas strictement aux spécifications, ou transformez-la en une valeur qui soit conforme. Ne vous fiez pas exclusivement à la recherche d'entrées malveillantes ou incorrectes (par exemple, ne comptez pas sur une liste noire). Toutefois, les listes noires peuvent être utiles pour détecter les attaques potentielles ou pour déterminer quelles entrées sont si mal formées qu'elles devraient être rejetées purement et simplement.

Lorsque vous effectuez une validation d'entrée, considérez toutes les propriétés potentiellement pertinentes, comme la longueur, le type d'entrée, la gamme complète des valeurs acceptables, les entrées manquantes ou défectueuses, la syntaxe, la cohérence dans des domaines connexes et la conformité aux règles métier. Comme exemple de logique de règle métier, "bateau" peut être syntaxiquement valide, car elle ne contient que des caractères alphanumériques, mais elle n'est pas valide si vous attendez des couleurs telles que "rouge" ou "bleu".

Utilisez une liste blanche des URL ou des domaines approuvés pour la redirection.

Utilisez une page d'avertissement intermédiaire signalant clairement à l'utilisateur qu'il quitte votre site. Mettez en place un long délai d'attente avant que la redirection se produise, ou forcez l'utilisateur à cliquer sur un lien. Veillez à éviter les problèmes XSS lors de la génération de la page d'avertissement.

Lorsque l'ensemble des objets admissibles, tels que les noms de fichier ou les URLs, est limité ou connu, créez une correspondance à partir d'un ensemble de valeurs d'entrée fixe (tels que des ID numériques) sur les noms de fichiers réels ou sur les URLs, et rejetez toute autre entrée.

Par exemple, ID 1 pourrait correspondre à "/login.asp" et ID 2 à "http://www.example.com/". Des librairies telles que ESAPI AccessReferenceMap fournissent cette fonctionnalité.

Assurez-vous que vous comprenez tous les secteurs potentiels où des entrées douteuses peuvent pénétrer dans votre logiciel: paramètres ou arguments, cookies, toute entrée en provenance du réseau, requêtes DNS inverses, résultats de requêtes, en-têtes de requêtes, composants d'URL, e-mails, fichiers, bases de données, et tout système externe fournissant des données à l'application. Rappelez-vous que de telles entrées peuvent être obtenues indirectement via des appels d'API.

Beaucoup de problèmes de redirection se produisent parce que le programmeur a assumé que certaines entrées ne pouvaient être modifiées, comme les cookies et les champs de formulaire masqués.

La réponse contient une redirection pour 'Refresh' dans sa balise meta http-equiv, ce qui permet de définir une Url externe.

http://projects.webappsec.org/URL-Redirector-Abuse

http://cwe.mitre.org/data/definitions/601.html

L'inclusion de fichiers distants (Remote File Inclusion - RFI) est une technique d'attaque exploitant les mécanismes "d'inclusion de fichier dynamique" (dynamic file include) dans les applications internet. Lorsque des applications web acceptent des entrées de l'utilisateur (URL, valeur de paramètres, etc.) et passent celles-ci dans les commandes de fichiers inclus, l'application web peut être trompée en incluant du code malveillant dans les fichiers distants.

Presque tous les frameworks d'application internet prennent en charge l'inclusion de fichiers. L'inclusion de fichier est principalement utilisée pour rassembler le code commun dans des fichiers distincts, qui sont référencés par la suite par les différents modules de l'application principale. Quand une application internet fait référence à un fichier inclus, le code du fichier peut être exécuté implicitement ou explicitement en appelant des procédures spécifiques. Si le choix du module à charger est basé sur les éléments de la requête HTTP, l'application internet peut être sujette à RFI.

Un agresseur peut utiliser RFI pour:

* exécuter du code malveillant sur le serveur: tout code trouvé dans les fichiers inclus malveillants va être exécuté par le serveur. Si le fichier inclus n'est pas exécuté à l'aide d'un wrapper quelconque, le code de ces fichiers inclus est exécuté dans le contexte de l'utilisateur du serveur. Ceci pourrait conduire à la prise de contrôle totale du système.

* Exécuter du code malveillant sur les clients : le code malveillant de l'agresseur peut trafiquer le contenu de la réponse envoyée au client. L'attaquant peut incorporer du code malveillant dans la réponse qui sera exécutée par le client (par exemple, du code Javascript pour voler les cookies de session du client).

PHP est particulièrement vulnérable aux attaques RFI, d'une part en raison de l'usage intensif de l'inclusion de fichiers en programmation PHP, d'autre part en raison des configurations par défaut des serveurs, qui augmentent le risque d'attaque RFI.

Phase: Architecture et Design

Quand l'ensemble des objets admissibles, tels que les noms de fichier ou URL, est limité ou connu, créez un mappage à partir d'un ensemble de valeurs d'entrée fixes (telles que des ID numériques) sur les URLs ou noms de fichiers réels, et rejetez toutes les autres entrées.

Par exemple, ID 1 pourrait correspondre à "inbox.txt" et ID 2 pourrait représenter "profile.txt". Des librairies telles que ESAPI AccessReferenceMap fournissent cette fonctionnalité.

Phases: Architecture et Design; Exploitation

Exécutez votre code dans un bac à sable ou un autre environnement similaire, qui impose des limites strictes entre le processus et le système d'exploitation. Cela peut restreindre efficacement quels fichiers sont accessibles dans un répertoire particulier ou lesquels peuvent être exécutés par votre logiciel.

Au niveau du système d'exploitation, on peut citer les exemples pour Unix: chroot, AppArmor et SELinux. En général, le code géré (managed code) peut offrir une certaine protection. Par exemple, java.io.FilePermission dans le SecurityManager de Java permet de spécifier des restrictions sur les opérations de fichiers.

Ceci peut ne pas être une solution adéquate. Par ailleurs, elle limite l'impact au seul système d'exploitation; le reste de votre application peut encore faire l'objet de vulnérabilités.

Veillez à éviter CWE-243 et d'autres failles liées aux environnements virtuels.

L'interprèteur PHP propose des restrictions telles que "open basedir" ou le mode sans échec, qui peuvent rendre plus difficile pour un agresseur de s'échapper de l'application. Envisagez également Suhosin, une extension PHP endurcie, qui comprend diverses options désactivant les fonctionnalités les plus dangereuses de PHP.

Phase: Implémentation

Partez du principe que toutes les entrées sont malveillantes. Utilisez une stratégie de validation des entrées basée sur le principe "n'accepter que le bon", c'est-à-dire utilisez une liste blanche des entrées acceptables se conformant strictement aux spécifications. Rejetez toute entrée ne se conformant pas strictement aux spécifications, ou transformez-la en une valeur qui soit conforme. Ne vous fiez pas exclusivement à la recherche d'entrées malveillantes ou incorrectes (par exemple, ne comptez pas sur une liste noire). Toutefois, les listes noires peuvent être utiles pour détecter les attaques potentielles ou pour déterminer quelles entrées sont si mal formées qu'elles devraient être rejetées purement et simplement.

Lorsque vous effectuez une validation d'entrée, considérez toutes les propriétés potentiellement pertinentes, comme la longueur, le type d'entrée, la gamme complète des valeurs acceptables, les entrées manquantes ou défectueuses, la syntaxe, la cohérence dans des domaines connexes et la conformité aux règles métier. Comme exemple de logique de règle métier, "bateau" peut être syntaxiquement valide car l'entrée ne contient que des caractères alphanumériques, mais elle n'est pas valide si vous attendez des couleurs telles que "rouge" ou "bleu".

Pour les noms de fichiers, utilisez des listes blanches rigoureuses qui limitent le jeu de caractères à utiliser. Dans la mesure du possible, ne permettez qu'un seul caractère "." dans le nom de fichier, pour éviter les failles comme CWE-23, et excluez les séparateurs de répertoire comme "/" pour éviter la CWE-36. Utilisez une liste d'extensions de fichier autorisées, ce qui contribuera à éviter CWE-434.

Phases: Architecture et Design; Exploitation

Stockez si possible les fichiers bibliothèque, include et utilitaire en dehors de la racine des documents internet. Sinon, stockez-les dans un répertoire distinct et utilisez le contrôle d'accès du serveur web pour empêcher les agresseurs de les référencer directement. Une pratique courante consiste à définir une constante fixe dans chaque programme appelant, puis à vérifier l'existence de la constante dans le fichier de bibliothèque/include; si la constante n'existe pas, alors le fichier a été directement demandé et l'exécution devrait stopper immédiatement.

Ceci réduit considérablement les risques qu'un attaquant soit capable de contourner les mécanismes de protection présents dans le programme de base, mais pas dans les fichiers include. La surface d'attaque en sera également réduite.

Phases : Architecture et Design; Implémentation

Assurez-vous de comprendre tous les secteurs potentiels où les entrées douteuses peuvent pénétrer dans votre logiciel: paramètres ou arguments, cookies, tout ce qui vient du réseau, variables d'environnement, requêtes DNS inverses, résultats de requêtes, en-têtes de requêtes, composantes d'URLs, courriels, fichiers, bases de données et tout système externe fournissant des données à l'application. Rappelez-vous que de telles entrées peuvent être obtenues indirectement via des appels d'API.

De nombreux problèmes d'inclusion de fichiers se produisent parce que le programmeur a assumé que certaines entrées ne pouvaient pas être modifiées, en particulier les cookies et les composants d'URL.

http://projects.webappsec.org/Remote-File-Inclusion

http://cwe.mitre.org/data/definitions/98.html

Le cross-site Scripting (XSS) est une technique d'attaque consistant à retourner du code fourni par l'attaquant à une instance de navigateur d'un utilisateur. Une instance de navigateur peut être un navigateur standard, un objet navigateur incorporé dans un produit logiciel (p.ex. le navigateur dans WinAmp), un lecteur RSS ou un client de messagerie. Le code lui-même est généralement écrit en HTML/JavaScript, mais peut être aussi en VBScript, ActiveX, Java, Flash ou toute autre technologie supportée par les navigateurs.

Lorsqu'un pirate parvient à faire exécuter son code par le navigateur d'un utilisateur, le code s'exécute dans le contexte de sécurité (ou zone) du site web hébergeur. Avec ce niveau de privilège, le code a la capacité de lire, modifier et transmettre toutes les données sensibles accessibles par le navigateur. Un utilisateur sujet au Cross-site Scripting pourrait voir son compte piraté (vol de cookie), son navigateur redirigé vers un autre site, ou éventuellement voir apparaître du contenu frauduleux envoyé par le site internet qu'ils visitent. Les attaques par Cross-site Scripting compromettent fondamentalement la relation de confiance entre un utilisateur et le site web. Les applications utilisant des instances d'objet de navigateur, et qui chargent du contenu depuis le système de fichiers, peuvent exécuter du code dans le périmètre de confiance de l'ordinateur, mettant ainsi en danger le système.

Il existe trois types d'attaques par Cross-site Scripting : non persistant, persistant et basé sur les DOM.

Les attaques non persistantes et celles basées sur les DOM nécessitent qu'un utilisateur visite un lien incorporant un code malveillant, ou visite une page web malveillante contenant un formulaire internet, qui, une fois publié sur le site vulnérable, permettra l'attaque proprement dite. Un formulaire malveillant sera souvent utilisé lorsque la ressource vulnérable n'accepte que les requêtes HTTP POST. Dans un tel cas, le formulaire peut être envoyé automatiquement, sans que la victime n'en ait conscience (p. ex. à l'aide de JavaScript). En cliquant sur le lien malveillant ou en soumettant le formulaire malveillant, le code XSS s'affichera en retour et sera interprété et exécuté par le navigateur de l'utilisateur. Une autre technique pour envoyer des requêtes presque arbitraires (GET et POST) consiste à utiliser un client intégré, tel que Adobe Flash.

Les attaques persistantes se produisent lorsque le code malveillant est envoyé à un site internet où il est stocké pendant un certain temps. Des exemples de cibles favorites des pirates sont les publications sur les tableaux de messages, les messages de courrier électronique et les logiciels de tchat internet. Aucune interaction avec un quelconque site/lien supplémentaire (par exemple, un site de pirate ou un lien malveillant envoyé par e-mail) n'est requis de la part de l'utilisateur sans méfiance, il suffit de visualiser la page internet contenant le code.

Phase: Architecture et Design

Utilisez une librairie ou un framework approuvé qui ne permet pas cette vulnérabilité, ou qui contient des fonctionnalités permettant d'éviter plus facilement cette vulnérabilité.

Quelques exemples de bibliothèques et de frameworks facilitant l'encodage approprié des pages internet sont: la bibliothèque Microsoft Anti-XSS, le module d'encodage OWASP ESAPI, et Apache Wicket.

Phases: Implémentation; Architecture et Design

Tenez compte du contexte dans lequel vos données seront utilisées et de l'encodage qui sera attendu. Ceci est particulièrement important lors de la transmission de données entre les différents composants, ou lors de la génération de sorties qui peuvent contenir plusieurs encodages en même temps, comme des pages internet ou des messages électroniques multi-parties. Étudiez tous les protocoles de communication et les représentations de données attendus pour déterminer les stratégies de codage requis.

Pour toutes les données qui seront affichées sur une autre page web, en particulier toutes les données qui ont été reçues de l'extérieur, utilisez l'encodage approprié pour tous les caractères non alphanumériques.

Consultez le XSS Prevention Cheat Sheet pour plus de détails sur les types d'encodage et d'échappement dont vous pouvez avoir besoin.

Phase : Architecture et Design

Pour tous les contrôles de sécurité effectués du côté client, veillez à ce que ces contrôles soient réitérés du côté serveur également, afin d'éviter la faille CWE-602. Les agresseurs peuvent contourner les contrôles côté client en modifiant les valeurs après que ces contrôles aient été effectués, ou en changeant le client afin d'en retirer complètement les contrôles. Ensuite, ces valeurs modifiées seraient soumises au serveur.

Le cas échéant, utilisez des mécanismes structurés appliquant automatiquement la séparation entre le code et les données. Ces mécanismes peuvent être en mesure de fournir automatiquement la présentation, le codage et la validation adéquat, au lieu de se fier au développeur pour réaliser ces fonctionnalités pour chaque champ de sortie généré.

Phase: Implémentation

Pour chaque page internet générée, utilisez et spécifiez un encodage de chaînes de caractères comme ISO-8859-1 ou UTF-8. Quand aucun codage n'est spécifié, le navigateur web tente de deviner quel encodage est effectivement utilisé dans la page web et peut choisir un codage erroné. Ceci peut pousser le navigateur internet à traiter spécialement certaines séquences, exposant ainsi le client à de subtiles attaques XSS. Voir CWE-116 pour des mesures de réduction de risque plus liées à l'encodage / l'échappement.

Pour aider à réduire les attaques XSS contre le cookie de session de l'utilisateur, fixez la valeur du cookie à HttpOnly. Dans les navigateurs prennant en charge la fonctionnalité HttpOnly (telles que les versions les plus récentes d'Internet Explorer et de Firefox), cet attribut peut éviter que le cookie de session de l'utilisateur soit accessible à des scripts malveillants utilisant document.cookie côté client. Ce n'est toutefois pas une solution complète, car HttpOnly n'est pas supporté par tous les navigateurs. Plus important encore, XMLHTTPRequest et d'autres puissantes technologies de navigateur fournissent un accès en lecture aux en-têtes HTTP, y compris à l'en-tête Set-Cookie, dans laquelle la balise HttpOnly est définie.

Supposez que toutes les entrées sont malveillantes. Utilisez une stratégie de validation des entrées basée sur le principe "n'accepter que le bon", c'est-à-dire utilisez une liste blanche des entrées acceptables se conformant strictement aux spécifications. Rejetez toute entrée ne se conformant pas strictement aux spécifications, ou transformez-la en une valeur qui soit conforme. Ne vous fiez pas exclusivement à la recherche d'entrées malveillantes ou incorrectes (par exemple, ne comptez pas sur une liste noire). Toutefois, les listes noires peuvent être utiles pour détecter les attaques potentielles ou pour déterminer quelles entrées sont si mal formées qu'elles devraient être rejetées purement et simplement.

Lorsque vous effectuez une validation d'entrée, considérez toutes les propriétés potentiellement pertinentes, comme la longueur, le type d'entrée, la gamme complète des valeurs acceptables, les entrées manquantes ou défectueuses, la syntaxe, la cohérence dans des domaines connexes et la conformité aux règles métier. Comme exemple de logique de règle métier, "bateau" peut être syntaxiquement valide car elle ne contient que des caractères alphanumériques, mais elle n'est pas valide si des couleurs sont attendues, telles que "rouge" ou "bleu".

Veillez à effectuer une validation d'entrée à des interfaces bien définies au sein de l'application. Ceci aidera à protéger l'application, même si un composant est réutilisé ou déplacé ailleurs.

http://projects.webappsec.org/Cross-Site-Scripting

http://cwe.mitre.org/data/definitions/79.html

L'en-tête X-Frame-Options n'est pas incluse dans la réponse HTTP pour protéger contre les attaques de 'ClickJacking'.

La plupart des navigateurs internet modernes supportent l'en-tête HTTP X-Frame-Options. Assurez-vous que celle-ci est renseignée sur toutes les pages internet retournées par votre site (si cette page ne doit être encadrée que par des pages de votre serveur (p.ex. fait partie d'un FRAMESET), alors utilisez la valeur SAMEORIGIN, sinon choisissez la valeur DENY quand la page n'est jamais encadrée. ALLOW-FROM permet à des sites spécifiques d'encadrer la page, pour autant que le navigateur le supporte).

http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Cette page contient un message d’erreur/avertissement qui peut divulguer des informations sensibles, comme l’emplacement du fichier qui a produit l’exception non gérée. Cette information peut servir à lancer d'autres attaques contre l’application web. L’alerte pourrait être un faux positif si le message d’erreur se trouve à l’intérieur d’une page de documentation.

Examinez le code source de cette page. Mettez en place des pages d’erreur personnalisées. Envisagez d’implémenter un mécanisme fournissant une référence/identificateur unique de l'erreur au client (navigateur), tout en journalisant les détails du côté serveur, les cachant ainsi à l’utilisateur.

Il est possible d'afficher la liste de répertoires. Cette liste peut révéler des scripts cachés, des fichiers d'inclusion, des sauvegardes de fichiers source etc. pouvant donner accès à des informations sensibles.

Désactiver la navigation dans les répertoires. Si la navigation est malgré tout nécessaire, assurez-vous que les fichiers répertoriés n'induisent pas de risques.

http://httpd.apache.org/docs/mod/core.html#options

http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html

La manipulation des paramètres a provoqué une page d'erreur ou l'affichage d'une trace d'appel Java. Ceci indique un défaut de gestion des exceptions et ouvre des potentialités pour d'autres exploits.

Identifiez la cause de l'erreur et corrigez-la. Ne pas faite confiance aux entrées côté client et appliquez un contrôle serré du côté serveur. En outre, interceptez proprement les exceptions. Utilisez une page d'erreur générique 500 pour signaler les erreurs internes du serveur.

La protection XSS du navigateur Internet n'est pas activée, ou est désactivée par la configuration de l'en-tête de réponse HTTP 'X-XSS-Protection' sur le serveur web

Assurez-vous que le filtre XSS du navigateur internet est activé, en renseignant l'en-tête de réponse HTTP X-XSS-Protection à '1'.

L'en-tête de réponse HTTP X-XSS-Protection autorise le serveur internet à activer ou désactiver le mécanisme de protection XSS du navigateur internet. Les valeurs suivantes tenteraient d'activer la protection:

X-XSS-Protection: 1; mode = block

X-XSS-Protection: 1; report = http://www.example.com/xss

Les valeurs suivantes désactiveraient cette protection:

X-XSS-Protection: 0

L'en-tête de réponse HTTP X-XSS-Protection est actuellement supportée par Internet Explorer, Chrome et Safari (WebKit).

Notez que cette alerte n'est déclenchée que si le corps de réponse pouvaient contenir une charge utile XSS (avec un type de contenu texte, d'une longueur différente de zéro).

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/

L'en-tête X-Content-Type-Options contre le sniffing MIME n'est pas renseigné à 'nosniff'. Ceci permet à de vielles versions d'Internet Explorer et de Chrome de pratiquer le sniffing MIME sur le corps de réponse, conduisant potentiellement à l'interprétation et l'affichage du contenu dans un autre type que celui déclaré. A l'heure actuelle (début 2014), les anciennes versions de Firefox utiliseront le type de contenu déclaré (au cas où un type est déterminé), plutôt qu'analyser le MIME.

Assurez-vous que l'application ou le serveur internet renseigne l'en-tête Content-Type correctement, et que l'en-tête X-Content-Type-Options prenne la valeur 'nosniff' pour toutes les pages internet.

Si possible, assurez-vous que l'utilisateur utilise un navigateur moderne et conforme aux standards, qui ne pratique pas du tout le sniffing MIME, ou qui puisse être commandé par l'application ou le serveur internet de manière à ne pas pratiquer le sniffing MIME.

Ce problème s'applique toujours aux pages de type erreur (401, 403, 500, etc.), car ces pages sont encore souvent touchées par des problèmes d'injection, auquel cas il est encore possible que les navigateurs interprétent des pages autrement que selon leur type de contenu réel.

http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx

https://www.owasp.org/index.php/List_of_useful_HTTP_headers

No Anti-CSRF tokens were found in a HTML submission form.

La contrefaçon de requête intersites (Cross Site Request Forgery - CSRF) est une attaque qui consiste à forcer une victime à envoyer une requête HTTP vers une destination cible, sans qu'elle n'en aie ni connaissance ni intention, afin d'effectuer une action en se faisant passer pour la victime. La cause originelle est que les fonctionnalités de l'application sont appelées à l'aide d'URL ou d'actions de formulaires prévisibles et reproductibles. La nature de l'attaque est que le CSRF exploite la confiance qu'un site internet accorde à un utilisateur. En revanche, le cross-site scripting (XSS) exploite la confiance que l'utilisateur porte à un site internet. Comme XSS, les attaques CSRF ne sont pas nécessairement multi-sites, mais elles peuvent l'être. La contrefaçon de requête intersite est également connue sous les noms CSRF, XSRF, attaque en un clic (one-click attack), session riding, confused deputy et sea surf.

Les attaques CSRF sont efficaces dans de nombreuses situations, notamment:

* quand la victime a une session active sur le site cible.

* quand la victime est authentifiée via HTTP auth sur le site cible.

* quand la victime est sur le même réseau local que le site cible.

CSRF a d'abord été utilisée pour effectuer une action contre un site cible en utilisant les privilèges de la victime, mais des techniques récentes permettent d'avoir accès à des renseignements en accédant à la réponse. Le risque de divulgation d'informations est considérablement augmenté lorsque le site cible est vulnérable aux XSS, parce que XSS peut être utilisé comme une plateforme pour CSRF, permettant à l'attaque d'opérer dans les limites de la politique de même origine.

Phase: Architecture et Design

Utilisez une librairie ou un framework approuvé qui ne permet pas cette vulnérabilité, ou qui contient des fonctionnalités permettant d'éviter plus facilement cette vulnérabilité.

Utilisez par exemple des librairies anti-CSRF telles que CSRFGuard de l'OWASP.

Phase: Implémentation

Assurez-vous que votre application soit exempte de problèmes de cross-site scripting, parce que la plupart des défenses contre le CSRF peuvent être contournées en utilisant des scripts contrôlés par le pirate.

Phase: Architecture et Design

Générez une valeur à usage unique pour chaque formulaire, placez-la dans le formulaire et vérifiez-la à la réception du formulaire. Assurez-vous que cette valeur unique ne soit pas prévisible (CWE-330).

Notez que ceci peut aussi être contourné en utilisant XSS.

Identifiez les opérations particulièrement dangereuses. Quand l'utilisateur exécute une opération dangereuse, envoyez une requête de confirmation distincte pour vérifier que l'utilisateur veut effectivement effectuer cette opération.

Notez que ceci peut aussi être contourné en utilisant XSS.

Utilisez la librairie de gestion de session ESAPI.

Cette librairie comprend un composant pour le contrôle de CSRF.

N'utilisez pas la méthode GET pour les requêtes entraînant un changement d'état.

Phase: Implémentation

Vérifiez l'en-tête HTTP Referer pour voir si la requête provient d'une page attendue. Ceci pourrait toutefois restreindre la fonctionnalité de l'application, car les utilisateurs ou les serveurs proxy pourraient avoir désactivé le renvoi du HTTP Referer pour des raisons de confidentialité.

No known Anti-CSRF token [anticsrf, CSRFToken, __RequestVerificationToken, csrfmiddlewaretoken, authenticity_token, OWASP_CSRFTOKEN, anoncsrf, csrf_token, _csrf, _csrfSecret] was found in the following HTML form: [Form 2: "search" "scope" "ignorecase" ].

http://projects.webappsec.org/Cross-Site-Request-Forgery

http://cwe.mitre.org/data/definitions/352.html

The response appeared to contain common error messages returned by platforms such as ASP.NET, and Web-servers such as IIS and Apache. You can configure the list of common debug messages.

Disable debugging messages before pushing to production.

Un cookie a été défini sans le flag HttpOnly, ce qui signifie que le cookie peut être accessible via JavaScript. Si un script malveillant peut être exécuté sur cette page, alors le cookie sera accessible et pourra être transmis à un autre site. Si il s’agit d’un cookie de session, alors le détournement de session pourra être possible.

Veiller que le flag HttpOnly soit défini pour tous les cookies.

http://www.owasp.org/index.php/HttpOnly

Une adresse IP privée comme 10.x.x.x, 172.x.x.x, 192.168.x.x a été trouvée dans le corps de la réponse HTTP. Cette information pourrait être utile pour d'autres attaques ciblant les systèmes internes.

Supprimez l’adresse IP privée du corps de réponse HTTP. Pour des commentaires, utilisez un commentaire JSP/ASP au lieu d'un commentaire HTML/JavaScript, qui peut être vu par les navigateurs clients.

192.168.0.6

192.168.0.6

192.168.0.6

192.168.0.6

https://tools.ietf.org/html/rfc1918